Video decoder with adaptive outputs

ABSTRACT

In one aspect, there is provided a video decoder including a first write port to write uncompressed video data to a first buffer in a first format adapted based on an input required by the video decoder and to suppress writing to the first buffer. The video decoder also includes a second write port to write uncompressed video data to a second buffer in a second format adapted to provide the uncompressed video data for subsequent processing external to the video decoder.

RELATED APPLICATION

This patent application is a continuation of U.S. patent applicationSer. No. 11/805,988, filed May 25, 2007, now issued as U.S. Pat. No.8,139,632 on Mar. 20, 2012, which is a continuation-in-part of U.S.patent application Ser. No. 11/728,016, filed Mar. 23, 2007, entitled“Video Decoder With Adaptive Outputs,” the contents of which are herebyincorporated by reference.

FIELD

The present disclosure generally relates to image processing.

BACKGROUND

Processing of video data often includes receiving a stream of video dataand rendering for presentation on a display device. The video dataincludes video frames and/or video fields. Typically, video frames aregenerated for presentation on composite display devices, such as cathoderay tube (CRT) monitors, high definition (HD) televisions, and/or liquidcrystal display (LCD) panels, while video fields are typically presentedon interlaced devices such as traditional television sets. A video codermay compress the video data before storage or transmission.

To display or further process the video data, the video data (alsoreferred to as image data, image data bit stream, digital video, orvideo data stream) may be processed by a variety of devices including avideo decoder. The video decoder may process (e.g., decompress) videodata compressed in accordance with a standard, such as H.264, MPEG-2,MPEG-4, VC-1, and the like. For example, the MPEG-2 standard prescribesan architecture for an MPEG-2 video decoder including aspects such as avariable length decoding section, an inverse quantization section, aninverse discrete cosine transform section, a motion compensator section,and memory. Likewise, the Blue Ray disc format prescribes H.264 forvideo compression of high definition (HD) video stored on the Blue Raydisc, and prescribes H.264 for the decompression of any video playedback from that disc. When the video decoder includes coding mechanisms(e.g., a compression section to compress uncompressed video data), thevideo decoder is referred to as a video coder-decoder (or codec).

The implementation of any video decoder architecture is complex and thuscostly. Moreover, the complex processing requires additional memory toprocess the video data and requires additional bandwidth to handle thecomplex processing. The additional memory may require substantial diearea on a chip, which increases the cost of implementing the videodecoder and its associated memory on an integrated circuit. Therefore,there continues to be a need to process video data in an efficientmanner.

SUMMARY

The subject matter disclosed herein provides methods and apparatus,including computer program products, for providing a video decoder.

In one aspect, there is provided a video decoder including a first writeport to write video data to a first buffer in a first format adaptedbased on an input required by the video decoder and to suppress writingto the first buffer based on the input. The video decoder also includesa second write port to write uncompressed video data to a second bufferin a second format adapted to provide the uncompressed video data forsubsequent processing external to the video decoder.

Variations may include one or more of the following features. Thewriting to the first buffer may be suppressed to adapt to a motioncompensation module. The writing to the first buffer may be suppressedto adapt to the motion compensation module, when the motion compensationmodule does not require one or more reference pictures from the firstbuffer. The first write port may include a first address calculationmodule for determining memory address information and controlinformation based on whether the video data is in a frame mode or afield mode and based on the first format. The first write port may alsoinclude a first data packing module for writing the video data to thefirst buffer at one or more locations determined by the addresscalculation module. The second write port may include a second addresscalculation module for determining memory address information andcontrol information based on whether the video data stream is in a framemode or a field mode and based on the second format. The second writeport may also include a second data packing module for writing the videodata to the second buffer at one or more locations determined by theaddress calculation module. The first write port may use the field modewhen the video data is interlaced and use the frame mode when the videodata is not interlaced. The determination of whether to write in theframe mode or the field mode may be made on a macroblock basis. Thefirst write port may also control the first write port to write thefirst format in a block of 16 by 16 when the video data input to thevideo decoder corresponds to H.264. The video decoder may also include amemory including one or more buffers for storing a first output of thefirst write port and for storing a second output of the second writeport. The first write port may also write video data to the first bufferin the first format adapted based on the input required by a motioncompensator section of the video decoder. The first write port maydynamically adapt writing of video data to the first buffer. The videodecoder may also include an application programming interface forreceiving a first call enabling configuration of the first write port towrite to the first buffer and for receiving a second call enablingconfiguration of the second write port to write uncompressed video datato the second buffer.

The subject matter described herein may be implemented to realize theadvantages of reducing memory bandwidth and providing more efficient useof memory when decoding video with a video decoder.

It is to be understood that both the foregoing general description andthe following detailed description are exemplary and explanatory onlyand are not restrictive. Further features and/or variations may beprovided in addition to those set forth herein. For example, theimplementations described herein may be directed to various combinationsand subcombinations of the disclosed features and/or combinations andsubcombinations of several further features disclosed below in thedetailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings,

FIG. 1 depicts a block diagram of a video decoder including a firstwrite port adapted for the video decoder and a second write port adaptedfor another device;

FIG. 2 depicts a block diagram of the video decoder of FIG. 1implemented in a high definition (HD) system;

FIG. 3 depicts an implementation of the write ports of the video decoderof FIG. 1; and

FIG. 4 depicts a process for providing two video decoder outputs, thefirst output adapted to the video decoder, and a second output adaptedto another device.

Like labels are used to refer to same or similar items in the drawings.

DETAILED DESCRIPTION

FIG. 1 depicts a system 100 including a video decoder 120, a memory 140,a splitter 160, and follow-on processing modules, such as an advancedvideo processor 180, a graphics processor 182, and one or more otherprocessing blocks 184.

The video decoder 120 receives video data as an input video bit stream105. The input video bit steam may be in any format including anycompressed video data format, such as MPEG-1, MPEG-2, MPEG-4, H.264, andVC-1. The video decoder 120 processes the input video bit stream 105using a variety of sections (also referred to as modules) including areverse entropy decoder 122 a, an inverse image transform (e.g., adiscrete cosine transform (DCT)) 122 b, a motion compensator 122 h, ade-blocker 122 e, a DB writer 122 f, and a DBW writer 122 g.

The reverse entropy decoder 122 a (also referred to as entropy decoding)is a technique used to decode large amounts of data by examining thefrequency of patterns within the data. In particular, a reverse entropydecoder may be used to decompress data by replacing symbols representedby codes (where the length of each codeword is proportional to thenegative logarithm of the probability) with symbols represented byequal-length codes. Examples of reverse entropy encoders and decodersinclude CABAC (Context-based Adaptive Binary Arithmetic Coding) andHuffman coding.

The inverse transform 122 b performs an inverse transform (e.g., a DCT)of the compressed video to decompress the video data. The inversetransform is often performed in blocks of pixels that are 8 pixels by 8pixels (8×8). The 8×8 block represents a portion of an image (e.g., aframe or fields) of video data. Once the video data has been processedby the inverse transform, additional decoding, such as inversequantization and motion prediction, is performed to further decompressand recover the original, uncompressed video data. Although FIG. 1depicts inverse transform 122 b, other coding and/or compressionmechanisms may be used.

Once inverse transform 122 b decompresses the video data, motioncompensator section 122 h generates the fully decoded video images.Motion compensator 122 h uses predictive coding to predict future framesfrom previous frames. For example, if an image sequence includes movingobjects, then their motion within an image scene (or sequence ofpictures) can be measured, and this information may be used to predictthe content of other frames in the sequence.

In some implementations, a context manager 122 c is used in videodecoder 120 to provide context information when decoding macroblocks. Inparticular, a frame of a video image may be divided into an array ofmacroblocks. In the case of H.264, video decoder 120 may process thevideo data as a 16×16 block of picture samples or pixels. For example,inverse transform, motion compensation, de-blocking, and the like mayprocess the video data in blocks of 16×16 pixels. In this example,information about the current macroblock being processed and anyneighboring macroblocks may be used as context information to enableprocessing by the video decoder 120.

De-blocker 122 e processes decompressed video images to smooth edgesbetween adjacent blocks. For example, an image having a size of 1920pixels by 1080 pixels may be divided into blocks of 8×8, 8×16, and16×16. However, when used, de-blocking may improve image quality bysmoothing the edges between blocks.

DB writer 122 f writes to one or more buffers, such as picture buffers144 a in memory 140. The DB writer 122 f is a write port for writing topicture buffer 144 a in a format adapted to the requirements of videodecoder 120, video input bit stream 105, and, in some cases, therequirements of picture buffer 144 a. In particular, video decoder 120may write to picture buffers 144 a to enable motion compensator 122 h aswell as other processing sections. Moreover, DB writer 122 f may beimplemented to write, under the control of a central processing unit(CPU) and firmware 122 d, in a variety formats (e.g., a tile formatand/or a linear format) to provide video data in a format required byvideo decoder 120 and its internal processing sections (or modules). Forexample, the fields of interlaced video data may be stored in buffer 144a in a linear format (i.e., a horizontal line of pixels of a video imageis stored in contiguous, increasing memory locations in picture buffer144 a) to provide a deinterlacer of video decoder 120 with video data ina format adapted for deinterlacing and field predication. Alternatively,video data may be stored in picture buffer 144 a as tiles (also referredto as blocks). The tiles may be defined by the type of video beingprocessed by the video decoder 120 (e.g., high definition motioncompensation usually requires an 8×8 block of pixels).

In some implementations, DB writer 122 f dynamically adapts the formatof the output written to picture buffer 144 a. For example, DB writer122 f may adapt the format based on picture level changes, so that ifthe so-called “pictures” in the video data change every 30 milliseconds,the output of DB writer 122 f may also adapt to such changes. Oneexample of such picture level changes is H.264 Macroblock-AdaptiveFrame/Field (MBAFF) coding. When a MBAFF mode is used in a compressedbit stream, field encoding or frame encoding may change from macroblockto macroblock. Moreover, the DB writer 122 may write in an interlacedformat or a progressive format based on the encoding used on any givenmacroblock. Furthermore, when MBAFF is used, the video data may changefrom an actual frame of actual picture information to one or more fillframes. In some implementations, DB writer 122 f suppresses writing topicture buffer 144 a when the video decoder 120 and/or its internalprocessing modules do not require so-called “reference” pictures.Reference pictures enable processing in the video decoder 120. Forexample, reference pictures may be used by motion compensator 122 h.

TABLE 1 below provides example output formats of DB writer 122 f andwhen they would be used. The formats listed in Table 1 (e.g., tiled,interleaved fields, etc.) may change (i.e., adapt) on a macroblockbasis, and information indicating the format of each macroblock can bestored and then used whenever each macroblock is processed (e.g., readfrom the picture buffer 144 a).

TABLE 1 Adapted Output Format Stored at Picture Buffer 144a Use Tiled,interleaved fields Motion compensation Tiled, stacked fields Motioncompensation Linear, interleaved fields Motion compensation Linear,stacked fields Motion compensation

DBW writer 122 g is a write port that writes in a variety formats (e.g.,a tile format and/or a linear format) to provide video data in theformat required for display and/or follow-on processing, both of whichare external to the video decoder 120. For example, the video output ofDBW 122 g may be written, under the control of firmware 122 d, topicture buffer 144 b in a linear format (e.g., a horizontal line ofpixels of a field of a video image is stored in contiguous, increasingmemory locations in picture buffer 144 b). The contiguous, increasingmemory locations in picture buffer 144 b are output to splitter 160 andan advanced video processor 180 for further processing beforepresentation at a monitor, HD television, or the like. In addition,video data may be stored in picture buffer 144 b as tiles for a graphicsprocessing unit 182 (e.g., 3-D graphics engine or graphics accelerator)for further processing and/or display. The output of DBW 122 g may bewritten to buffer 144 b in a digital display format, such as YUV, YCbCr,and the like. The output format of the DBW writer 122 g is adapted torequirements external to the video decoder 120, such as the requirementsof a follow-on graphics-processing unit or the requirements for adisplay. TABLE 2 below provides example formats and when they would beused.

TABLE 2 Adapted Output Format Stored at Picture Buffer 144b Use 16 × 16,8 × 8, tiled, stacked H.264 video video post-processing fields, etc.(color space conversion, re-sampling, de-interlacing, etc.) 16 × 16, 8 ×8, tiled, Video post-processing (color space interleaved fields, etc.conversion, re-sampling, de-interlacing, etc.) Linear, stacked fieldsDe-interlacing and other video post- processing operations Linear,interleaved fields De-interlacing and other video post- processingoperations

The memory 140 may be implemented as any form of memory including RAM(random access memory), DRAM (dynamic RAM), SRAM (Static RAM), and anyother mechanism of electronic data storage. Although FIG. 1 depictsmemory 140 as separate from video decoder 120, in some implementations,memory 140 may be included within the same package or die as videodecoder 120.

FIG. 2 depicts an example implementation of video decoder 120. Thesystem 200 is similar in many respects to FIG. 1, but further depicts ahigh definition (HD) data source 205, such as an HD-DVD or a Blue Raydisc. These HD data sources 205 provide compressed video data compliantwith H.264. The HD data source 205 provides compressed video data thatis stored at buffer 244. The buffer 244 then provides the H.264 videodata to video decoder 120 as input video bit stream 105. Under thecontrol of an embedded CPU 122 k and firmware 122 d, video decoder 120provides decompressed video data in a digital format (e.g., YUV orYcbCr) to picture buffer 144 b, which subsequently provides thedecompressed video data to a downstream device 250, such as a display, agraphics engine, or the like.

The system CPU 220 and a register file 270 configure video decoder 120and DBW writer 122 g to provide an output adapted to the H.264 videoinput. The register file 270 may also include information to configureDB writer 122 f to provide an output adapted to the H.264 video input aswell as the sections of video decoder 120.

In some implementations, video decoder 120 includes an applicationprogramming interface (API), which can be called by an external device,such as a DVD player, media player (e.g., Windows Media Player), HD datasource 205, and the like. For example, a device, such as a Windows MediaPlayer or Blue Ray DVD player, may read a specific type of media (e.g.,H.264 formatted video data), and a component, such as an interface, atthe device may then call the API of video decoder 120 to provideinformation to enable the configuration of DB writer 122 f and buffer144 a as well as the configuration of DBW writer 122 g and picturebuffer 144 b. Based on information provided by the device, the callwould enable adaptation (e.g., writing or suppressing) of the format ofthe output provided to buffers 144 a and 144 b.

FIG. 3 depicts an implementation of the write ports of DB writer 122 fand the DBW writer 122 g. The DB writer 122 f may include addresscalculation logic 405 for determining the memory address locations inwhich to write video data. The DB writer 122 f may also include a datapacking module 410 for preparing the data for writing to memory 140. Forexample, if a frame of a video image were interlaced, each horizontalline (e.g., a field) of pixels would be stored in contiguous memoryaddress locations in picture buffer 144 a. In this example, addresscalculation logic 405 may receive an initial base address and dataformat. Moreover, address calculation logic 405 may also receive anindication that the mode is field as well as X, Y coordinate pixelinformation. Given the aforementioned, address calculation logic 405calculates the memory address for each pixel of the field (i.e., memoryaddress for each pixel of the horizontal line of pixels) and providescontrol signals for writing to memory 140. Meanwhile, data packingmodule 410 receives a video data (e.g., a horizontal line of pixels) andorganizes the video data for writing at the calculated address of memory144 a.

In the case of a frame of a video image in a tile format (e.g., in 16×16blocks), each block in the frame of pixels would be stored in contiguousmemory address locations in picture buffer 144 a. The addresscalculation logic 405 would receive an initial base address and dataformat, image size, image resolution, an indication that the mode isframe since the video data is non-interlaced (e.g., progressive) videodata, and X, Y coordinate pixel information. Next, address calculationlogic 405 calculates the memory address for the video data associatedwith each pixel of the block (e.g., a 16×16 block) and provides controlsignals to enable writing to memory 140. Meanwhile, data packing module410 receives a block and organizes the block for writing in contiguousmemory addresses. For example, video data associated with the top leftmost pixel of a 16×16 block may be written to memory 140 first, and thevideo data associated with the remaining 15 pixels in the top row may besubsequently written to memory 140 before writing video data for otherpixels in the next row of the block, although other writing schemes maybe used instead. Outputs of module 405 and 410 are the memory address,memory data, and various control signals necessary to perform the writecycles to memory buffers 144 a. Outputs of module 415 and 420 are thememory address, memory data, and various control signals necessary toperform the write cycles to memory buffers 144 b.

The frame/field mode inputs to address calculation logic 405 and datapacking 410 are provided by a configuration register, which can bewritten to by a processor using firmware. The frame/field mode inputs toaddress calculation logic 415 and data packing 420 are provided byanother configuration register, which can be written to by a processorusing firmware. The pixel stream inputs of data packing modules 410 and420 is provided by a de-blocker module, which produces the de-blockedblock of pixels to be used by a motion predictor (e.g., as referenceframes) or to be used by video post-processing modules. The x,ycoordinates, pixel type inputs of address calculation logic 405 and 415are provided by a de-blocker module. The x,y coordinates, pixel typeinformation represents display screen locations of the associated pixelstream data as well as the type of pixel data. The type of pixel datamay indicate that certain pixels are supposed to be written to certainmemory buffers and only by DB writer 122 f. The data format input ofdata packing 410 is provided by a configuration register, which can bewritten to by a processor using firmware. The data format input of datapacking 420 is provided by another configuration register, which can bewritten to by a processor using firmware.

FIG. 4 depicts a process for video decoding using two write ports, onewrite port adapted to write in a format dictated by the video decoder,and another write port adapted to write in another format dictated byanother device, such as a display or follow-on processor. At 410, videodecoder 120 receives compressed video data, such as input video datastream 105.

At 420, video decoder 120 processes input video data stream 105, so thatthe video data is decompressed. For example, video decoder 120 mayinclude an inverse DCT section to process the compressed video data toyield decompressed video data.

At 430, video decoder may write using DB writer 122 f the uncompressedvideo data to picture buffer 144 a. The video data written to picturebuffer 144 a may be formatted based on the requirements of the videodecoder 120. In some implementations, DB writer 122 f may write topicture buffer 144 a in a format adapted for an input of one of thesections of video decoder 120. For example, DB writer 122 f may write topicture buffer 144 a video data formatted as reference frame images foruse by motion compensator 122 h.

In some implementations, DB writer 122 f may suppress writing to picturebuffer 144 a. The video decoder 120 may receive video data correspondingto pictures that do not require one or more reference pictures (e.g.,very static scenes may not require motion compensation). When this isthe case, video decoder 120 detects (e.g., using aspects of H.264) thatreference pictures are not required and adapts the format of the outputof DB writer 122 f. In this example, DB writer 122 f may adapt itsoutput by suppressing (e.g., not writing) video data (e.g., referencepictures) to buffer 144 a. Alternatively, DB writer 122 f may suppresswriting to picture buffer 144 a by writing so-called “fill” data (e.g.,dummy data) to picture buffer 144 a.

At 440, video decoder 120 may write using DBW writer 122 g video data topicture buffer 144 b. The video data written to picture buffer 144 b isformatted based on the requirements of components external to videodecoder 120. For example, video data written by DBW writer 122 g topicture buffer 144 b may be formatted in 16×16 blocks for a 3-D graphicengine or may be written in another digital format for presentation. Insome implementations, video decoder 120 may more efficiently processvideo data by using two write ports (e.g., DB writer 122 f and DBWwriter 122 g), each adapted to write to buffers 144 a and 144 b using aspecified format—thus minimizing waste of memory resources at buffers144 a and 144 b when compared to approaches using a single write port.

In some implementations, the subject matter described herein may use twowrite ports to decouple internal memory buffers of a video decoder fromoutput memory buffers of a video decoder, so that, for example, a videoplayer application may dictate, on a frame-by-frame basis, the format ofthe decoded video data output.

Although the above describes de-interlacing as part of the videodecoder, de-interlacing may also be implemented as part of advancedvideo processor 180.

Moreover, although the above describes particular image processingprotocols as examples (e.g., H.264 and VC1), embodiments may be used inconnection any other type of image processing protocols and standards.Although the above describes a video decoder, a video encoder may alsobe implemented using aspects similar to those described above.Furthermore, any implementations described herein might be associatedwith, for example, an Application Specific integrated Circuit (ASIC)device, a processor, a video encoder, video decoder, video codec,software, hardware, and/or firmware. In addition, to simplify theexplanation of the features of the subject matter described herein,FIGS. 1 and 2 depict simplified video decoders including only some ofthe sections, which may be included in a video decoder. Although theabove describes the use of two write ports within the context of a videodecoder, a device other than a video decoder may implement the two writeports described herein.

The systems and methods disclosed herein may be implemented as acomputer program product, i.e., a computer program tangibly embodied inan information carrier, e.g., in a machine readable storage device or ina propagated signal, for execution by, or to control the operation of,data processing apparatus, e.g., a programmable processor, a computer,or multiple computers. A computer program can be written in any form ofprogramming language, including compiled or interpreted languages, andit can be deployed in any form, including as a stand-alone program or asa module, component, subroutine, or other unit suitable for use in acomputing environment.

The foregoing description is intended to illustrate but not to limit thescope of the invention, which is defined by the scope of the appendedclaims. Other embodiments are within the scope of the following claims.

1-18. (canceled)
 19. A system for decoding video having adaptiveoutputs, the system comprising: a video decoder that receives video dataas an input video stream and processes the received video stream usingat least one module, wherein the video decoder includes a contextmanager that provides context information related to the received videodata to enable processing of the received video data by the videodecoder wherein the context information includes macroblock informationassociated with a macroblock included in the video stream andneighboring macroblock information associated with neighboringmacroblocks of the macroblock.
 20. The system of claim 19 furthercomprising at least one processing module that further processes thereceived video data.
 21. The system of claim 20 wherein the at least oneprocessing module comprises an advanced video processor that providesprocessing before presentation of the video data on an output display.22. The system of claim 20 wherein the at least one processing modulecomprises a graphics processor that provides at least one of furtherprocessing before presentation of the video data on an output displayand presentation of the video data on an output display.
 23. The systemof claim 20 wherein the at least one processing module comprises one ormore processing blocks.
 24. The system of claim 19 wherein the at leastone module comprises a reverse entrophy encoder that decodes video databy examining the frequency of patterns within the video data.
 25. Thesystem of claim 19 wherein the at least one module comprises an inverseimage transform that performs an inverse transform of the video data toprovide decompressed video data.
 26. The system of claim 19 wherein theat least one module comprises a motion compensator.
 27. The system ofclaim 19 wherein the at least one module comprises a de-blocker thatprocesses the video data to smooth edges between adjacent blocks of datawithin the video data.
 28. The system of claim 19 wherein the at leastone module comprises a DB writer that writes the video data to one ormore buffers.
 29. The system of claim 19 wherein the at least one modulecomprises a DWB writer that writes the video data in a format forpresentation.
 30. The system of claim 19 wherein the processing uses afirst write port adapted to write in a format dictated by the videodecoder and a second write port adapted to write in a second formatdictated by a device.
 31. A method of processing video data, the methodcomprising: receiving by a video decoder a video data as an input videostream; processing the received video stream using at least one module;and providing context information related to the received video data toenable the processing, wherein the context information includesmacroblock information associated with a macroblock included in thevideo stream and neighboring macroblock information associated withneighboring macroblocks of the macroblock.
 32. The method of claim 31further comprising processing the video data in at least one additionalmodule.
 33. The method of claim 32 wherein the at least one processingmodule comprises an advanced video processor that provides processingbefore presentation of the video data on an output display.
 34. Themethod of claim 32 wherein the at least one processing module comprisesa graphics processor that provides at least one of further processingbefore presentation of the video data on an output display andpresentation of the video data on an output display.
 35. The method ofclaim 32 wherein the at least one additional module comprises one ormore processing blocks.
 36. The method of claim 31 wherein the at leastone module comprises a reverse entrophy encoder that decodes video databy examining the frequency of patterns within the video data.
 37. Themethod of claim 31 wherein the at least one module comprises an inverseimage transform that performs an inverse transform of the video data toprovide decompressed video data.
 38. The method of claim 31 wherein theat least one module comprises a motion compensator.
 39. The method ofclaim 31 wherein the at least one module comprises a de-blocker thatprocesses the video data to smooth edges between adjacent blocks of datawithin the video data.
 40. The method of claim 31 wherein the at leastone module comprises a DB writer that writes the video data to one ormore buffers.
 41. The method of claim 31 wherein the at least one modulecomprises a DWB writer that writes the video data in a format forpresentation.
 42. The method of claim 31 wherein the processing uses afirst write port adapted to write in a format dictated by the videodecoder.
 43. A computer-readable storage medium containing instructionsto configure a processor to perform a method, the method comprising:receiving by a video decoder a video data as an input video stream;processing the received video stream using at least one module; andproviding context information related to the received video data toenable the processing, wherein the context information includesmacroblock information associated with a macroblock included in thevideo stream and neighboring macroblock information associated withneighboring macroblocks of the macroblock.
 44. The computer-readablestorage medium of claim 43 wherein the processing uses a first writeport adapted to write in a format dictated by the video decoder.